home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1599 / 1396 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  4.0 KB
  1. Date: Mon, 16 May 94 14:26 CDT
  2. From: ekl@sdf.lonestar.org (Evan K. Langlois)
  3. To: mint@atari.archive.umich.edu
  4. Subject: readonly files
  5.  
  6.  
  7. ========================================================================
  8.  Hmmm, wrong. MiNT (or the denyaccess() routine) does very well allow root
  9. to open a readonly file for writing. The problem is that you must ignore the
  10. reported filemode and just try it. Most programs seems to self-check the
  11. file modes before trying to open the file, and therefore fail. I've seen
  12. some GNU tools and editors doing this.
  13. ========================================================================
  14.  
  15. Nope, it's checked after denyacess is called I think.  There is an extra
  16. check for it, anyway, dosfile.c.   I quote :
  17.  
  18. /*
  19.  * an extra check for write access -- even the superuser shouldn't
  20.  * write to files with the FA_RDONLY attribute bit set (unless,
  21.  * we just created the file, or unless the file is on the proc
  22.  * file system and hence FA_RDONLY has a different meaning)
  23.  */
  24.  
  25.  
  26. ========================================================================
  27. > IMHO, the biggest problem of MiNT is its compatibility with TOS.
  28.  
  29.  :-)
  30. ========================================================================
  31.  
  32. No, TOS compatibility is MiNTs biggest asset.  Without it, MiNT is nothing.
  33. There are no super-apps for MiNT, and as a Unix, it falls short.  Lets
  34. face it, MiNT can't compete with any workstation version of Unix around,
  35. and its NOT because of TOS compatibility!   MiNT isn't gonna compete with
  36. a SUN or a NeXT.  If you want a real Unix, then get one!!  Mach is availble
  37. for FTP - get it, port it, and when your done, write a TOS server to run
  38. old St apps.
  39.  
  40. MiNT's biggest plus is that you can run those TOS apps that people bought
  41. an ST to run, like Pagestream, MIDI programs (well, a few will run under 
  42. MiNT), and similar programs.  People aren't gonna shell out big money on
  43. ATARI harware (ATARI hardware =IS= overpriced) just to run MiNT on a text
  44. screen with no GEM, no port of X, nothing,  It won't happen.  Therefore,
  45. be as TOS compatibile as possible in the kernel, and when that conflicts
  46. with the needs of POSIX, ajust the library to compensate - either that or
  47. create a new domain.
  48.  
  49. Here's my guidline for a new domain :
  50.  
  51. Domain X : 
  52.   No XBIOS or BIOS access except by the super-user.  No VDI or AES access
  53. except by the super-user.  Pdomain() cannot change to TOS or MiNT domain (but
  54. maybe others).  Remove calls Fsfirst/Fsnext, Dsetdrv/Dgetdrv, Dgetpath (use
  55. Dgetcwd).  All paths are relative to drive U: - cannot change drives.  All
  56. the XBIOS and BIOS functions that alter memory blocks (Getmpb, etc) or do
  57. direct disk access (Getbpb, Drvmap, Rwabs) and the interrupt control 
  58. functions (Setexec, etc) are removed - not even Super-user can use them.
  59. Bconin/Bconout stuff may be used by super-user and XBIOS sound stuff may
  60. be used by super-user.   Also, domain is inherited by children of this 
  61. domain.  All OS calls work as POSIX as possible.
  62.  
  63. MiNT domain :
  64.   VDI+AES+XBIOS are restricted to super-user.  All other functions are
  65. as-is (unless buggy!), except Super(), Supexec(), Rwabs(), Setexec(), etc,
  66. (the dangerous ones) are restricted to super-user.   Otherwise, this is
  67. MiNT domain.
  68.  
  69. TOS domain :
  70.   Totally 100% TOS compatible, other than the fact that you can get access
  71. to pipes, and multitask and such.
  72.  
  73.  
  74. By making init a domain 3 process, remote users are restricted.  Most apps
  75. should function in the MiNT domain (GEM stuff).  Unix utils would function
  76. in domain 3 (maybe a new executable format that automatically starts app
  77. in domain 3, compatible with a.out format??)
  78.  
  79. Anyway .. it's just a thought .. it could save us from the TOS vs. Unix
  80. battles.  After all, that is what Pdomain is for!!
  81.  
  82.  
  83. CYA
  84. Evan K. Langlois
  85. ekl@sdf.lonestar.org
  86.  
  87. PS: even if the offical version of MiNT won't support this 3rd domain, you
  88. could begin hacking up a the domain anyway - things like not returning EPTHNF
  89. for ENOENT or whatever would differ between domain X and MiNT domain, and
  90. TOS domain would be EPTHNF + always 8+3 upper-case, etc.
  91.  
  92.  
  93. l
  94.